1. Field of the Invention
This invention relates to data processing systems running applications written for the specific first processor of the first processing system having input/output devices, and more particularly to a system and method of simulating the I/O interrupts of the first processing system for running the applications on a second processing system having a second dissimilar processor and having the input/output devices of the first processing system attached to the second processing system.
2. Description of the Related Art
Current advances in computer technology have lead to ever changing processors, otherwise referred to herein as the central processing unit (CPU), of the processing system. Examples of the evolution of various processors are Intel's 8088 processor used in the IBM PC, Intel's 80286 processor used in the IBM PC AT, Intel's 80386 processor used in the IBM Personal System/2 model 80, and the IBM Research/ OPD Microprocessor (ROMP) which utilizes a Reduced Instruction Set Computer (RISC) architecture in the IBM RT PC. Other processors include Motorola's 68000, 68020 among others.
The hardware of various processing systems changes rapidly to take advantage of the increased processing power of emerging processors. A disadvantage of changing hardware is that the software written for previous processors typically can not be used on the later hardware technology. In some cases where it can be used on a different processing system other than the one it was originally written for, the performance of the application is not as good on the different processing system as it would have been on the processing system for which the application was originally written. As a result, software applications which may have had a long development cycle may become quickly obsolete. The demise of the earlier written software is all the more tragic when the function of the application as originally written is still very much pertinent and in demand on the new hardware processing systems.
As a result, there is typically only a limited amount of "new" software available that is specifically written for the "new" hardware design when the new hardware is initially released into the market place. This is due in part by the long development cycle of creating software application programs, and the confidentiality of the new hardware design by the manufacturer prior to releasing the hardware into the market place. The software manufacturer has to know certain facts about the hardware of a processing system before a software application program can be written for the processing system.
Ideally, a manufacturer of processing systems would like to have a vast amount of software available to run on the processing system as soon as the new hardware for the processing system is announced into the market place. A customer would more likely invest in a new processing system if the customer knows that an abundant supply of software is already available for use.
There have been several approaches in tapping the vast amount of software that has previously been written for "older" hardware designs. A previous hardware approach for being able to run applications originally written for another processor is to build the new processing system with a coprocessor. In this way, the processing system can run applications for both types of processors, the new processor and the old processor.
For example, the IBM RT PC contained an IBM PC AT coprocessor in order to use applications that were originally written for the IBM PC AT. However, since the coprocessor was supported at a low level in the operating system, the coprocessor could not take full advantage of the functions provided by the AIX operating system. One of the functions provided by the AIX operating system is multi-tasking as described in co-pending U.S. patent application Ser. No. 820,451, filed Jan. 17, 1986 for a VIRTUAL TERMINAL SUBSYSTEM and assigned to the same assignee as the present invention, which is herein incorporated by reference.
The coprocessor, however, limits the user to one session at a time, since the coprocessor included a hardware adapter for emulating the PC AT. In other words, once the coprocessor was started, no other instances of the coprocessor could be running. The coprocessor is also limited to the speed of the processor of the first processing system and cannot take advantage of faster second processing systems as they evolve.
A second approach is to simulate the second processor through software. A software simulator provides a mechanism to run previously written software for one processor on a new processing system having a different processor. A software approach to simulation allows taking advantage of faster second processing systems as they evolve. It allows the use of multasking capabilities of the operating system to provide multiple instances of the first processor.
Some software simulators on the market today include SoftPC, by Insignia Solutions, and the Amiga Transformer by Simile Research Inc. for Commodore's Amiga (based on Motorola's 68000). Information on this system was published in the article "Amiga's Trump Card: IBM PC Emulation", AMIGA WORLD, Vol. 1, No. 2, November/December 1985. Phoenix Technologies also provided a simulator to simulate the Intel processor for the Apollo machine which has a Motorola 68000 processor.
Any specific CPU processor has a specific instruction set. When a software application program is developed for a specific CPU processor, it is compiled into object code. The object code is targeted to run on any CPU that supports the specific instruction set. A simulator takes object code that was written to run on a specific instruction set, and converts it to run on a different processor which may have a similar or different instruction set. The more the two instruction sets of the two processors are different, the more difficult it is to simulate the other processor.
For example, the Intel 80286 processor has a very rich instruction set in that it provides a wide variety of instructions. Each instruction is tailored specifically for a particular type of situation. Additionally each instruction may be able to do several operations. In contrast, the ROMP processor in the RT PC has a reduced instruction set (RISC) processor which provides fewer instructions and less function per instruction. As each instruction in the Intel 80286 may be able to do several tasks, more instructions would be required with the ROMP RISC processor to accomplish the same tasks.
However, the speed of a processor can be increased by simplifying the instruction set. Although more instructions are required, no additional time is consumed on complicated instructions while executing the more common and simpler tasks.
Previous methods of software simulators created a subroutine that would simulate the effect of an instruction. Every time the machine being simulated needed to run that instruction, the subroutine would be called in order to decode and execute that instruction. The problem with this approach is that the overhead of decoding the instruction occurs every time the subroutine is called and executed. Consequently, the speed of the simulated processor is affected.
Instead of calling a subroutine each time an instruction needed to be executed, another software simulation approach compiled a shorter sequence of host machine instructions to simulate an instruction. As a result, the overhead of decoding and translating the instruction occurs only once, during the first time the instruction is encountered. This translation is then saved. From then on, every time that instruction is simulated, the translation is executed. This is often referred to as a second generation simulator. A first generation simulator will take an instruction one at a time and decode it in real time and execute it. The decoding is done for each instruction as each instruction is needed. A second generation simulator will go through the instructions one at a time, translate the instructions, and then reuse that translation instead of going back and translating again.
A previous second generation simulator was the simulator that simulated the ROMP CPU on the IBM System/370 called RSIM. This simulator reserves a fixed amount of storage for each instruction (16 bytes for every halfword) called cells. IBM 370 instructions would then be generated for each one of these cells for each RT instruction. If the amount of code generated is less than what would fit in one cell, which is usually the case, then it branches to the next boundary of the next cell. If the amount of code generated to simulate the instruction can not fit into one cell, then a subroutine call is generated that branches to a run time environment set of routines which perform the emulation and return back to the cell to complete execution. Another simulator simulates the processor of the IBM System/370 on the IBM RT PC which is described in the following article: May, C., "Mimic: A Fast System/370 Simulator", presented Jun. 11, 1987 at the Association of Computing Machinery Symposium on Interpreters and Interpretive Techniques", and published in SIGPLAN, 1987 proceedings of ACM.
A first generation simulator runs 50 to 100 host machine instructions per simulated instruction. A second generation simulator runs an average of 10 host machine instructions per simulated instruction.
If a simulator takes either 50 or 10 instructions to simulate one instruction on the simulated machine, the second processor running the simulator must be either 50 or 10 times as fast respectively as the simulated machine to be comparable in performance. It is therefore desirable to further reduce the number of simulator instructions per each simulated or translated instruction than what has previously been accomplished in the art.
For example, if a simulator could be designed to use only 4 instructions per simulated instruction, and the simulator processor is more than 4 times faster than the simulated machine processor, the simulator will be faster than the original machine being simulated. A user would then observe increased performance by using the simulated machine to run an application program than by using the machine for which the application program was originally written.
Therefore, the overall problem to overcome in simulating another processor is to further reduce the number of simulator (host) instructions per simulated instruction in order to increase the processing speed of the simulator.
However, if an application program which was written for a different processing system is to be executed, there is more than just the CPU processor that needs to be simulated efficiently. One major area in simulating a different processing system involves simulating accurately and efficiently the various aspects of the I/O of the first processing system while also simulating the processor of that first processing system. It is important not to degrade the performance of the CPU simulator while simulating I/O devices attached to the processing system. This is especially true when attempting to simulate an interrupt from an I/O device.
One major problem in using a software simulated CPU is in getting hardware interrupts from a physical adapter to the software simulated CPU without degrading its performance.